home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0964.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  1.7 KB  |  37 lines
  1. Tim BL writes:
  2. >This is always what you expect, except that it might
  3. >surprise you if you don't think too hard that in directory
  4. >/a/fred, "bert" refers to /a/bert, not /a/fred/bert, so
  5. >/a/fred/bert should be referred to as "fred/bert" or "./bert".
  6. >Anyway, you are right, and if there are browsers which do otherwise
  7. >that is their problem, unless I've goofed.
  8.  
  9. The last example is really worrysome!  If you are trying to follow
  10. UNIX conventions, "./bert" should refer to the same thing as "bert",
  11. so it would refer to "/a/bert"!  What does the library code actually
  12. do?  (I don't have it handy!)
  13.  
  14. Another question about this subject is resolution of "../" prefixes.
  15. In the above example, what does "../foo" refer to?  I'd hope "/foo".
  16.  
  17. Also, who is supposed to do the ".." resolution -- the client or the
  18. server?
  19.  
  20. And what about "/../" in the middle of a path?  Does
  21. "/foo/bar/../bletch" always mean "/foo/bletch" (if "/foo/bar" were a
  22. symbolic link to a directory, it won't on UNIX, meaning that a client
  23. doing "../" stripping might wind up at a different place than a server
  24. blindly following the path (which might be dangerous if there are more
  25. "../" parts than allowed -- I don't know if servers allow this).
  26.  
  27. Finally, I believe there are (or were) some gateway servers on the net
  28. that are confused about this themselves: when in /a/b and attempting
  29. to generate a relative reference to c, they would end up referring to
  30. /a/b/c instead of /a/c, or when attempting to refer one level up they
  31. would point to /a/a instead of /a.  (I seem to remember the CERN Emacs
  32. Info gateway did this -- can't find where it is right now...)
  33.  
  34. --Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
  35.  
  36.  
  37.